The Internet has changed the way people communicate. For many people, electronic mail, known as “e-mail,” has practically replaced traditional letters and in some instances, telephone calls, as the primary means of communication. Users of the Internet send literally millions of e-mail messages across the Internet on a daily basis. The popularity of being able to send messages anywhere in the world in a matter of minutes, or even seconds, has made e-mail the most rapidly accepted form of correspondence to date. The use of e-mail has risen from obscurity, used once only by academics and the military, to dominant mode of public communication in less than twenty years.
However, in our fast-paced world where the desire for access to more information at a faster rate increases on a daily basis, the once rapid response of e-mail communications is no longer fast enough to keep pace with society's need. One way to help people communicate faster was the creation of instant messaging (“IM”) services. IM services allow for nearly real time communications because the users sending and receiving messages are continually connected to an IM service. The speed at which recipients get IM messages is determined by the speed the data can travel across the Internet. When a subscriber logs into an IM service, the service lets an IM server know that the user is available to receive messages. To send a message to a recipient, the subscriber simply selects the name of the recipient, usually from a contact list that contains the recipient's IM address, and types the message.
The core of IM is based on the concept of “presence management,” which determines where a user is connected to the Internet, the availability of the user, and on what system the user resides. Similar to email, a system level designation (domain) is the first tier of recognizing where to reach a particular user. IM, however, requires at least two additional elements (location and status) that make up the core of presence management. The immediate nature of this type of communication requires that the exact IP address of the person and their willingness to accept a message be known in order to set up a connection.
IM was initially available to only dial up Internet users, which made location specific information extremely important. In the last couple of years the access of IM services has spread across mobile devices, such as cellular telephones, personal digital assistants (PDAs), and almost any system capable of Internet access. This proliferation has added the need to manage other elements of presence that did not exist in the past. With the potential to have multiple devices active, such as PC, PDA, cellular telephone, pager, etc., the presence system must be able to identify and manage each Internet device connected to the Internet and determine to which device messages should be forwarded.
To accommodate the rapid growth in IM, each Internet Service Provider (ISP) developed their own brand of technology to locate and connect users within their community. In doing so, each ISP selected different methods for managing presence and setting up communications paths between two parties. Unfortunately, these methods do not allow users of one system to easily contact and communicate with users of other systems. There is a need to enable effective intersystem communication and provide a path to grow future interoperability without negatively affecting the current separate networks in operation.
Currently, ISPs use one of three methods to transmit instant messages between subscribers on their network. The first method uses a centralized network, in which subscribers are connected to one another through a series of network servers. The individual servers are linked together to form a large, centralized network. In this architecture, each server keeps track of the presence information and connections for each user connected to the network. When a subscriber sends a message, the server determines the location of the recipient's computer by contacting all of the other network servers and routes the message through the network servers until it reaches the recipient. This particular method is used by Microsoft Network (MSN) Messenger IM service.
A second method of transmitting instant messages uses a peer-to-peer architecture favored by systems using ICQ protocol (pronounced “I seek you”), such as the Yahoo!® Messenger IM service. In the peer-to-peer approach, a central ICQ server keeps track of which subscribers are currently online and records their Internet IM protocol addresses. Once a subscriber logs on to the ICQ server, the ICQ server scans the subscriber's contact list and displays to the subscriber the Internet IM protocol address of every person on the contact list currently logged onto the IM server. When the subscriber wants to send a message to a recipient on the ICQ server, the subscriber simply selects the name of the recipient, types a message, and transmits the message. Because the ICQ client on the subscriber's computer has the Internet Protocol IM address of the recipient, the message is sent directly to the ICQ client residing on the recipient's computer without involving the ICQ server. This method has an advantage over the centralized network system because the messages do no travel through the entire network, which speeds the transfers of large files, such as documents and images because they are not slowed by network traffic.
When the conversation is complete, the subscriber exits the IM program, at which point the ICQ client on the subscriber's computer generates a message to the ICQ server to terminate the session. The ICQ client then sends a message to each ICQ client on the subscriber's contact list, that are currently logged onto the ICQ server, indicating that the subscriber has terminated his session.
The last method of transmitting instant messages is using a hybrid system that combines the centralized network approach with the peer-to-peer approach. America On Line's (AOL®'s) Instant Messaging (“AIM”) service currently uses this method. The AOL® AIM service uses the centralized network approach for transmitting text messages and performing presence management. Because text messages are usually small, transmitting them over the network does not noticeably slow their delivery. However, for large files, such as document and images, AOL® AIM service uses ICQ protocol to establish a peer-to-peer connection between the subscriber and the recipient of the message.
Unfortunately, each of the current IM services lacks a coherent standard. Each IM service uses a separate proprietary protocol to implement instant messaging on their network. As a result, a user can only receive presence information and send messages to individuals that are registered with the same IM service as the sender. Thus, the lack of a standard protocol for IM severely limits the potential application of IM by restricting the number of potential recipients to those users registered on the same service as the sender of the IM message.
An example of a traditional instant messaging architecture is shown in FIG. 1. The traditional IM architecture consists of a central IM server 105 connected to a number of individual IM clients (110, 115, 120, 125, 130, and 145) in a closed network. To send an IM, from client 110 to client 145, IM client 110 first connects with an IM server 105 using a proprietary protocol. For example, AOL® and Yahoo!® use ICQ. Once the IM client 110 is connected to the IM server 105, the user logs on by entering a user name and password. The IM client 110 then sends the IM server 105 the connection information, such as the IP address and number of the port assigned to the IM client and the name and address of everyone in the IM contact list associated with the IM client 110.
The IM server 105 then creates a temporary file that contains the connection information for the IM client 110 and for each IM client. Once the temporary files have been created, the IM server 105 checks the network to determine whether any IM client identified by the contact list associated with IM client 110 is currently logged into the system. If the IM server 105 finds any of the contacts logged onto the network, the IM server 105 sends a message back to the IM client 110 with the connection information for each IM client currently logged onto the network. When the IM client 110 receives the connection information, the status of that particular IM client is updated to “Online,” which is displayed to the user. At this point the user may select any IM client that is registered “Online,” at which point a dialog box will appear in which the user may enter text. Because the IM client 110 knows the address and port number of the IM client 145 the message is sent directly to the recipient IM client 145. The IM client 145 then receives the instant message and can respond. Once the IM session is complete the dialog box is closed and the IM client 110 goes offline and sends a message to the IM server 105 terminating the session. The IM server 105, in response to acknowledging that the IM client 110 has logged off, generates a message to each of the IM clients on the client list of IM client 110 indicating that IM client 110 is logged off the network.
A major drawback to this system is that each IM client that a user wishes to communicate with must be connected to the IM server and must be part of the network due to the proprietary nature of the protocol. If the IM client happens to lie outside the IM network, he or she will not be able communicate with anyone in the network.
One solution to the interoperability problem is an attempt by the Internet Engineering Task Force (IETF) to develop a standard protocol for instant messaging known as Instant Messaging Presence Protocol. Many of the IM service providers have been working within the IETF to develop a standard IM protocol. However, because each IM service provider has spent considerable capital developing a format for instant messaging, the IETF has yet been unable to establish a standard protocol.
Another solution to the interoperability problem is JABBER, which is an IM system focused on providing IM access to any user from anywhere using any device and interoperability with IM services. JABBER is Extensible Markup Language (XML) open source server software that was developed by a community of developers over the Internet. JABBER allows communication among applications and systems across all platforms. Developers write additional modules to submit them back for possible incorporation into the JABBER software. Unfortunately, most of the IM services do not use XML as their IM format. Therefore, to achieve interoperability between the IM services, JABBER requires a translation module to translate the IM message in XML format into each of the formats used by the separate IM services. Therefore, the JABBER system adds additional cost and complexity to the IM infrastructure.
A block diagram illustrating a prior art IM network that uses JABBER Interoperable XML-Based Network architecture is shown in FIG. 2. JABBER is a real-time communications platform based on open protocols and Extensive Markup Language (XML), and whose architecture is based on the well-known electronic mail system. Because JABBER is based on the email system, the JABBER architecture contains distributed network servers, called JABBER servers 215, and clients, known as JABBER clients 200, 205, 210, that receive and send messages to JABBER clients connected to any JABBER server on the Internet. However, unlike typical email systems, which are store and forward systems, JABBER delivers messages in real time because the JABBER server 215 knows when a particular JABBER client is online.
Two features of JABBER make it unique over common prior art IM systems. First, JABBER uses an open protocol that allows interoperability among various IM systems. Second, JABBER is based on XML, which allows for easy and reliable structured messaging between software applications.
The JABBER architecture is based on client-server architecture and not on a client-to-client architecture, as are most IM systems. Messages from JABBER client 200 to JABBER client 210 must pass through the JABBER server 215. Each JABBER client is attached to a local JABBER server 215. Each local JABBER server 215 receives information from one JABBER client 200 and transfers the information to another JABBER client along with presence information. Each local JABBER server 215 functions independently from one another, and can communicate with any other JABBER server that is connected to the Internet as long as it has been identified, and predisposed to do so ahead of time.
Each local JABBER server 215 performs two functions: listening for and communicating directly with JABBER client applications, and communicating with other JABBER servers. Each local JABBER server 215 consists of multiple components that separately handle individual functions with the JABBER system. At the core of the local JABBER server 215 is a deliver component 220, which performs the following tasks: session management, client-to-server communications, server-to-server communications, group chat, storing messages for JABBER clients currently offline, DNS resolution, user authentification, user registration, database lookups filtering messages for offline users, and the like.
Additionally, each JABBER server 215 contains “transports” 225, 230, and 235 that communicate with other servers operating under protocols that are foreign to JABBER's open XML format. The transports act as translators between the deliver component 220 of the local JABBER server 215 and a third party instant messenger server. Each transport contains their own session manager that translates JABBER XML into and out the “foreign” protocol for presence, messaging, and information/query requests. In general, when a client logs onto the JABBER server 215, a thread is created in the transport to handle all communication from that client. Typically, the translation to and from JABBER XML is straightforward when the foreign protocol is well documented, as in the case of IRC protocols, and the AIM protocol. However, for other foreign protocols that are poorly documented, such as Yahoo!® Instant Messenger, the translation to and from JABBER XML can either be difficult and slow. Currently, transports are available to translate to and from the following protocols: AOL® AIM, ICQ, IRC, MSN Messenger, Rich Site Summary (RSS ver. 0.9), and Yahoo!® Instant Messenger.
As an example, when the JABBER client 200 wishes to communicate with a client 245 on a third party instant messenger server 240, such as AOL Instant Messenger, the JABBER client 200 first generates a message which is sent to the local JABBER server 215. The message contains JABBER ID that contains the name of the third party instant messaging server 240 (e.g., johndoe@aim.goabber.org). The local JABBER server 215 routes the message to the appropriate translator, which in the illustration is Translator 225. If the Translator 225 is running locally on the local JABBER server 215, the JABBER server 215 communicates directly with the Translator 225. If, however, the Transport 225 is running remotely, the JABBER server 215 passes the XML packet to the remote server, which then forwards it onto the Translator 225. After the local JABBER server 215 has passed the message to the Translator 225, the Translator 225 translates the XML packet into a native packet, which is readable by the third party instant messenger server 240. The third party instant messenger server 240 in turn, passes the translated packet onto the appropriate client 245.
The Jabber architecture relies heavily on translators and is constrained by its ability to keep up with each provider's protocol, and method of handling presence. Thus, there is a need in the art for a simple, cost effective IM network architecture that uses a universal IM presence and interconnection methodology that is compatible with the existing IM Service Provider networks.